System and method for reliably purging a fault server

ABSTRACT

Improvements to existing trap-generated message memory purge procedures and processes are shown and described. The improvements may be implemented in a telecommunications system having a plurality of managed elements, each of the managed elements potentially generating traps which are communicated to one or more fault servers.

I. BACKGROUND

A. Field of the Invention

This invention relates generally to the field of network management, andmore particularly to maintenance operations on elements within a managedtelecommunications network.

B. Copyright Notice/Permission

A portion of the disclosure of this patent document contains materialthat is subject to copyright protection. The copyright owner has noobjection to the reproduction by anyone of the patent document or thepatent disclosure as it appears in the Patent and Trademark Officepatent file or records, but otherwise reserves all copyright rightswhatsoever. The following notice applies to the software and data asdescribed below and in the drawings hereto: Copyright. COPYRGT.2001-002,BellSouth Intellectual Property Management Corporation.

C. Description of the Related Art

Telecommunications companies (i.e., service providers) build, operate,and maintain very large communications and related networks. Part of theoperation and maintenance of these networks involves the use ofoperations software, typically divided into a number of functional areassuch as engineering, provisioning, and the like. Provisioning softwareaids service providers in receiving requests for service or alterationsto existing service, be it voice and/or data, and configuring both thetelecommunications network and/or related networks and systems (e.g.,accounting, billing, and the like) to provide the new service requested.Engineering operations software in contrast is typically used by serviceproviders to configure and monitor network elements to ensure theyperform their functions properly. Service providers also use engineeringoperations software to facilitate service provisioning and monitoring.

One of the primary engineering operations software systems is theelement management system (EMS) software. Typical EMS packages arecentralized service network management applications that manage andcontrol (typically via standards such as SNMP and the like) the variouselements in the telecommunications and/or related networks. Within thecore telecommunications network the elements often are multiserviceelements such as frame relay, SMDS, ATM, IP, and/or the like switches.Some of the operations performed by typical EMS packages include:circuit provisioning to establish end-to-end network connectivity;logical provisioning of individual circuits and to establishnetwork-wide parameters; providing audit trails on activities such asthe length of a user session and the addition or modification ofswitches, logical ports, trunks, circuits, and the like; display ofnetwork statistics for real-time status information on logical andphysical ports; display of usage data on logical and physical ports andthe like for network planning and trend analysis; and collectingdifferent types of traps for alarm indications and statistics loggingfor the numerous objects in the telecommunications networks (e.g.,switches, trunks, physical ports, logical ports, permanent virtualcircuits, switched virtual circuits, and the like).

With regard to traps in particular, the EMS package typically reportsall traps from the various elements in the network being managed to acentral repository comprised of one or more fault servers and/or relateddatabases. However, with the explosive growth in demand fortelecommunications services over the past few years the number ofelements within the service providers' networks have dramaticallyincreased. As a result, the number of faults occurring in serviceproviders' networks has swelled, thereby generating so many traps at asuch a rapid pace that existing systems and methods of collecting,analyzing, and managing these traps have been overwhelmed. Accordingly,there is a need for improved systems and methods of collecting andmanaging traps in telecommunications and/or related networks.

II. SUMMARY OF THE INVENTION

In a telecommunications system having a plurality of managed elements,each of the managed elements potentially generating traps which arecommunicated to one or more fault servers, an improved fault messagepurge procedure, the improvement comprising an increased rowcount, theincreased rowcount corresponding to approximately 45,000 rows in atrap-generated message memory for approximately every traps received atthe one or more fault servers. The purge procedure may call a purgescript residing in the one or more fault servers. The purge proceduremay also be initiated by a second script residing in a UNIX segment ofthe one or more fault servers. Existing purge procedures are improved bymonitoring one or more of any processes contained within the purgeprocedure and restarting the purge procedure upon detection of anyerrors in the processes.

III. BRIEF DESCRIPTION OF THE DRAWINGS

These and other features, aspects, and advantages of the invention willbecome better understood in connection with the appended claims and thefollowing description and drawings of various embodiments of theinvention where:

FIG. 1 illustrates and an exemplary network within which the inventionmay be implemented; and

FIG. 2 illustrates the structure of an exemplary server that may residewithin a network such as that illustrated in FIG. 1.

IV. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Throughout the following detailed description similar reference numbersrefer to similar elements in all the figures of the drawings.

FIG. 1 illustrates an exemplary network 101 in which the invention maybe implemented. Network 101 is based in part on the EMS developed andmarketed by Lucent Technologies of Murray Hill, N.J. under the trademarkNAVISCORE. The NAVISCORE EMS is a distributed multiservice elementmanager that utilizes a graphically integrated UNIX-based platform andtelecommunications network management (TNM) standards to perform itsnetwork management and control functions. Network 101 also includesportions of a suite of management servers developed and marketed byLucent Technologies under the trademark NAVISEXTEND ENVIRONMENT. TheNAVISEXTEND ENVIRONMENT extends the functionality of the NAVISCORE EMS.Network 101 as depicted includes a plurality of fault servers 102 andstatistics servers 103 operatively connected to a private network 104.Network 101 also includes a fault database 105 and a statistics database106 operatively connected to private network 104. As will be understoodby one skilled in the art, network 101 need not include many of theelements depicted therein (e.g., statistics servers 103, firewalls, DMZnetwork 108, and the like), and may include any number of other elementsnot depicted in FIG. 1 (e.g., provisioning servers, accounting servers,and the like).

In operation, whenever a switch or managed network element (not shown)in the telecommunications network 107 experiences a fault it generates atrap. The trap is subsequently communicated from the network element toat least one of the fault servers 102 via a demilitarized zone (DMZ)network and the private network 104. The fault server 102 converts thetrap into an English language-type message (not shown) that typicallyincludes information such as the type of error experienced by thenetwork element, a date and time the error occurred, the particularnetwork element that experienced the error (e.g., by network addresssuch as an IP address), and the like. In some of the assignee of thepresent invention's networks, receipt of 50-100 traps per second at thefault servers 102 is not unusual. The English language-type message isthen sent by the fault server 102 to the fault database 105 via theprivate network 104, where the message is stored and may be accessed byother systems in the network for analysis, troubleshooting, and thelike.

While one skilled in the art will understand that servers 102 may beimplemented in any number configurations on any number of computingplatforms, FIG. 2 illustrates a generic computing platform 201 forservers 102. As shown, computing platform 201 includes processing unit222, system memory 224, and system bus 226 that couples various systemcomponents including system memory 224 to the processing unit 222. Thesystem memory 224 might include read-only memory (ROM) and/or randomaccess memory (RAM). The platform 201 might further include a hard-drive228, which provides storage for computer readable instructions, datastructures, program modules, other data, and the like. A user may entercommands and information into the platform 201 through input devicessuch as a keyboard 240 and pointing device 242. A monitor 244 or othertype of display device may also be connected to the platform 201 forvisual output. Communications device 243, which may be for example aTCP/IP enabled device, provides for connectivity to other computingdevices within or beyond network 101 illustrated in FIG. 1. Processor222 may be programmed with instructions to interact with other computingsystems so as to perform the algorithms and operations described below.Processor 222 may be loaded with any one of several computer operatingsystems such as Windows NT, Windows 2000, Linux, and the like. In aparticular embodiment of the invention, processing unit 222 comprises a4×450 MHz CPU, system memory 224 comprises 4 Gigabytes of RAM,hard-drive 228 comprises a 36 Gigabyte disk-drive, and processor 222includes a UNIX segment.

Because the information contained in the stored messages generated fromthe traps becomes stale at some point and the amount of storage space inthe fault database 105 is necessarily limited, a purge script is runperiodically to expunge a predetermined number of older error messagesstored in the fault database 105. In one configuration of the faultservers 102 the purge script calls on a Sybase stored procedure thatresides in a UNIX-based segment of fault database 105. Optimally, oldererror messages would be kept for the duration of their usefulness whileno fresh error messages would be lost due to insufficient storage spacein the fault database 105. The developers of existing purge scriptshowever failed to anticipate the sheer number of traps likely generatedby the elements in service providers' networks. The existing purgescripts therefore failed to allocate enough system resources to handlethe volume of traps generated in current networks, failed to purge anadequate number of stale messages stored in the fault servers, and/orfailed to provide for the appropriate periodicity of execution.

We have determined a number of ways that existing purge scripts may beimproved so that a more appropriate number of stale or older storedmessages are expunged, a more appropriate number of newly generatedmessages from traps are retained in memory, and the periodicity of thepurge process is adjusted to ensure no system errors are generatedbecause insufficient system resources are available to the purge processand/or the process is overwhelmed by the sheer number of messages beinggenerated in response to traps received from the various networks.Typically memory within a database or memory table is allocated by row.We have determined that in a database or memory where a row comprisesapproximately 1 kilobytes of memory for alarms and about 1.5 kilobytesof memory for traps (generated from alarms), and there is approximately5 Gigabytes of memory allocated for storage of up to ten days worth oftraps and alarms, purging the last 45,000 rows of memory will freeadequate storage space where a fault server(s) receives approximately 15traps per second from the various networks reporting to it, and wherethe purge process or script is mm approximately hourly. For example, inone embodiment of the invention where the fault servers 102 arereceiving approximately 50-100 traps per second, the purge script is runhourly with a rowcount set to free or return up to 1,500,000 rows ofmemory in fault database 105. Pseudocode for a revised purge script(“fs_purge.script”) appears in Appendix A attached hereto. In anexemplary embodiment of the invention a Unix script (“fsPurge.sh”)residing in a UNIX segment of fault servers 102 is the procedure thatcalls or initiates the purge script (“fs_purge.script”) which resides inthe fault database 105. Pseudocode for exemplary “fsPurge.sh”instructions is attached hereto as Appendix G.

Another improvement we have determined can be made to existing purgeprocedures is the addition of instructions to the procedure or processthat initiates the purge script. Some of these additional instructionscount each insertion and deletion of a trap-generated message frommemory in hourly periods and then place the data gathered in a log file(“fs_inserts.script”, “fs_stats.script”, and “fs_stats_hr.script”). Thisinsertion and deletion data subsequently may be analyzed fortroubleshooting or optimization of the purge process. Pseudocode forexemplary embodiments of these additional instructions appear inAppendices B, C, and D attached hereto.

Another set of additional instructions that may be added to the purgeprocedure is a script that monitors the fault server processes relatedto purging operations and automatically restarts them if problems aredetected such as a fault database deadlock message. Pseudocode forexemplary embodiments of these additional instructions (“fault_cron” and“check_insert.sh”) appear in Appendices E and F attached hereto. Notethat these two scripts monitor the log file noted above in conjunctionwith the fs_inserts and fs_stats scripts.

Note that the exemplary embodiments of the invention illustrated in thevarious appendices attached hereto are designed for the purge procedureto be run hourly, preferably every hour on the hour. Note also thatinstructions for the exemplary embodiments depicted in the appendicesalso provide for the purge procedure to restart up to ten times,separated by one minute intervals, in the case of fatal errors. Thishelps to ensure that a complete purge is completed even if the purgescript and/or the procedure it calls deadlocks or is killed by theserver or database respectively.

While the invention has been described in connection with variousexemplary embodiments depicted in the various figures and appendices, itis to be understood that other embodiments may be used or modificationsand additions may be made to the described embodiments for performingthe same function of the invention without deviating therefrom. Theinvention therefore should not be limited to any single embodiment,whether depicted herein or not. Rather, the invention should be accordedthe full breadth and scope encompassed by the claims appended below.

1. A fault message purge procedure comprising the improvement of anincreased rowcount, the increased rowcount comprising approximately45,000 rows in a trap-generated message memory for approximately every15 traps received at a corresponding fault server.
 2. The procedure ofclaim 1 comprising the further improvement of maintaining a log file ofall insertions and deletions of trap-generated messages in thetrap-generated message memory.
 3. The procedure of claim 1 comprisingthe further improvement of monitoring all insertions and deletions oftrap-generated messages in the trap-generated message memory to ensureall purge processes are functioning properly.
 4. The procedure of claim4 wherein any of the purge processes identified as not functioningproperly are restarted.
 5. The procedure of claim 1 comprising thefurther improvement of monitoring one or more of any processes containedwithin the purge procedure and restarting the purge procedure upondetection of any errors in the processes.
 6. A fault message purgeprocedure comprising the improvement of monitoring one or more of anyprocesses contained within the purge procedure and restarting the purgeprocedure upon detection of any errors in the processes.
 7. In atelecommunications system having a plurality of managed elements, eachof the managed elements potentially generating traps which arecommunicated to one or more fault servers, an improved fault messagepurge procedure, the improvement comprising an increased rowcount, theincreased rowcount corresponding to approximately 45,000 rows in atrap-generated message memory for approximately every 15 traps receivedat the one or more fault servers.
 8. The procedure of claim 7 whereinthe purge procedure calls a purge script residing in the one or morefault servers.
 9. The procedure of claim 7 wherein the purge procedureis initiated by a second purge script residing in a UNIX segment of theone or more fault servers.
 10. The procedure of claim 7 comprising thefurther improvement of maintaining a log file of all insertions anddeletions of trap-generated messages in the trap-generated messagememory.
 11. The procedure of claim 7 comprising the further improvementof monitoring all insertions and deletions of trap-generated messages inthe trap-generated message memory to ensure all purge processes arefunctioning properly.
 12. The procedure of claim 11 wherein any of thepurge processes identified as not functioning properly are restarted.13. The procedure of claim 7 comprising the further improvement ofmonitoring one or more of any processes contained within the purgeprocedure and restarting the purge procedure upon detection of anyerrors in the processes.